Use the following guidelines to help keep your server cluster from being adversely affected by denial of service attacks, data tampering, and other malicious attacks:
Only allow authorized personnel to have physical access to the server cluster nodes and related infrastructure components (for example, the network and storage components). For more information about standard best practices for securing servers, see Best practices.
For public or mixed networks: Ensure that all servers (for example, infrastructure servers such as DNS or WINS servers) that are attached to the cluster subnet (or any other subnet) are secure and trusted. Also, use a firewall to protect your cluster from unauthorized client access.
For private networks: Physically disjoint the private network(s) from other networks. Specifically, do not use a router, switch, or bridge to join a private cluster network to any other network. Do not include other network infrastructure or application servers on the private network subnet.
If heartbeat messages that are carried by private or mixed networks are disrupted (for example, by unauthorized users flooding the cluster networks), the cluster's reaction to these false failures may affect not only groups with IP address resources, but also the health of the cluster nodes. Repeated failover of critical cluster resources (for example, resources associated with Microsoft Exchange Server) may cause clients to lose access to the cluster.
If the remote computers are compromised, untrustworthy or malicious code can be started unknowingly by the cluster administration tools and adversely affect the cluster itself.
By giving the minimal possible administration rights and permissions to the Cluster service account, you avoid potential security issues if that account is compromised. For more information on the administration rights and permissions required by the Cluster service account, see To change the account under which the Cluster service runs.
This will limit exposure to the account with fewer administration rights and permissions than the Cluster service account. For more information on using another user account to administer a cluster, see To give a user permissions to administer a cluster.
This will limit exposure to the application and not the cluster account if an application account is compromised. In addition, if you use cluster.exe to change the password for the Cluster service account and one or more applications also use that account, your cluster applications may not function correctly. For more information, see To change the Cluster service account password.
This will limit exposure to one cluster only if a Cluster service account is compromised.
The cluster administration tools will not automatically delete the Cluster service account when all nodes have been evicted from the cluster. The Cluster service account has a high level of administration rights and permissions and that can present potential security issues if it is compromised; it is highly recommended that you remove this account from the local Administrators group if you no longer have use for it. However, because the administrative rights and permissions for the Cluster service account are granted locally on each cluster node and not domain wide, the impact of a compromised account is limited to just the cluster nodes. For more information on deleting user accounts, see Delete a local user account.
To ensure that only trusted personnel have user rights and permissions to administer the cluster and to track additions of unauthorized user accounts, audit changes to the local Administrators group. Note that, by default, when you create a server cluster or add nodes, the Cluster service account is added to the local Administrators group on each node. For more information on auditing security events, see Auditing security events.
If you want to audit access to shared data, enable auditing on all cluster nodes. For more information, see Securing shared data in a cluster.
Use
To help reduce the risk of unauthorized reads and writes to the quorum disk, it is highly recommended that you give access to the quorum disk only to the Cluster service account and members of the local Administrators group. For the Cluster service to start and continue to write to the quorum log, the quorum disk must have sufficient free space. It is recommended that the quorum disk be at least 500 megabytes (MB) in size. For more information, see Checklist: Planning and creating a server cluster and Disk resource security.
For more information, see Disk resource security.
Use NTFS file-level security for execute permissions on script files and permissions for APIs called in those scripts. For more information, see Limiting client access to cluster resources.
For more information, see Limiting client access to cluster resources.
After using the New Server Cluster Wizard and the Add Nodes Wizard from a remote computer, the cluster configuration log file generated by those wizards is saved to the remote computer (at
Note
In a majority node set server cluster, each node maintains a copy of the quorum database in the cluster directories located at
By default, only members of the Administrators group in the Builtin folder and the local system account have Full Control of the HKEY_LOCAL_MACHINE system registry subtree. If this registry subtree is compromised, some resources (for example, the Generic Script resource) may fail to start. For more information on securing the system registry, see Maintain registry security.
For more information on security in a server cluster, see Managing security in a cluster.